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Abstract 

As NASA Project Risk Management 
activities continue to evolve, the need to 
successfully integrate risk management 
processes across the life cycle, between 
functional disciplines, stakeholders, various 
management policies, and within cost, schedule 
and performance requirements/constraints 
become more evident and important. Today’s 
programs and projects are complex undertakings 
that include a myriad of processes, tools, 
techniques, management arrangements and 
other variables all of which must function 
together in order to achieve mission success. 
The perception and impact of risk may vary 
significantly among stakeholders and may 
influence decisions that may have unintended 
consequences on the project during a future 
phase of the hfe cycle. In these cases, risks may 
be unintentionally and/or arbitrarily transferred 
to others without the benefit of a comprehensive 
systemic risk assessment. Integrating risk 
across people, processes, and project 
requirements/constraints serves to enhance 
decisions, strengthen communication pathways, 
and reinforce the ability of the project team to 
identify and manage risks across the broad 
spectrum of project management 
responsibilities. The ability to identify risks in 
all areas of project management increases the 
likelihood a project will identify significant 
issues before they become problems and allows 
projects to make effective and efficient use of 
shrinking resources. By getting a total team 
integrated risk effort, applying a disciplined and 
rigorous process, along with understanding 
project requirements/constraints provides the 
opportunity for more effective risk management. 
Applying an integrated approach to risk 
management makes it possible to do a better job 


at balancing safety, cost, schedule, operational 
performance and other elements of risk. 

This paper will examine how people, 
processes, and project requirements/constraints 
can be integrated across the project lifecycle for 
better risk management and ultimately improve 
the chances for mission success. 

Introduction 

Risk Management has always been a 
part of the NASA management culture. 
However, in recent years the management of 
risk has taken on a more heightened level of 
importance. It has been a hot topic, especially in 
the Aerospace industry where more often than 
not it has been relegated to safety and hazardous 
circumstances. Although this perspective is very 
real and relevant, contemporary risk 
management must include many other aspects of 
the project such as cost, schedule, politics, parts, 
test, staffing, organizational factors, and other 
elements that could potentially lead to a failure 
in delivering projects within cost, schedule and 
operational requirements/constraints. This 
perspective has to be taken because of the 
complexities and interdependencies associated 
with many of today’s projects. As a means to 
manage all project risk it is imperative to 
approach risk management in an integrated, 
systematic, and disciplined manner so that the 
important risks are identified, resourced 
properly, and mitigated to an acceptable risk 
level. Integrated risk management brings 
together engineering and project management 
processes, along with all the stakeholders such 
as contractors, supplies, partners, academia and 
others as a resource to help decision makers 
make better decisions. This kind of risk 
management provides the systemic and 



The People part of Integrated Risk 
Management 

Most NASA projects are complex and 
involve many internal and external 
organizations. The people part of integrated risk 
management will address how to get the internal 
as well as the external organizations to work 
with one another in performing project risk 
management. Most projects unknowingly start 
with weak risk management requirements. They 
have poor agreements, contractual arrangements 
and management commitment. At best, they end 
up doing a decent job at running down problems 
and reacting to short-term risk. They start the 
project with good intentions but create a 
stovepipe risk management process that has 
each stakeholder off doing their own risk 
management activity instead of working with 
one another. The project essentially ends up 
with the government team, the contractor team, 
suppliers, partners, and other stakeholders doing 
their own independent risk management activity 
without talking to one another until there is a 
real problem. This process has the illusion of 
integrated risk management but doesn’t carry 
the same punch. This type of management is 
reactive and detrimental to risk management. It 
tends to eventually overshadow risk 
management and push it to the back burner. 
Many managers must get away from the notion 
that “there are-my risks” and “there-are-your- 
risks” because if any one part of the team fails 
the entire project could fail. The people part of 
integrated risk management deals with all the 
stakeholders on the project and how they can be 
used as a resource to provide the best 
information for decision makers. Integrated risk 
management looks at all the stakeholders as an 
integrated product team. The philosophy 
removes the “us- and- them” mentality and 
breeds an overall one-team “Big-us” mentality 
that cherishes open communication and 
discussion about all project risk. Using the rich 
diversity of people and their expertise and 
knowledge on the project provides an 
opportunity to see a very healthy dialogue that 
makes for a better understanding of the risk 
likelihood and impact. In any project 


management endeavor people are involved and 
one must consider their role in the risk 
management activity. This must be done from 
the individual level, and the functional 
organizational level. How a project is organized 
and how the different functional disciplines 
work with one another must be considered as a 
vital part of risk management. Systems 
engineering, systems assurance management, 
procurement management, financial 
management, project management, and 
executive management personnel are just a few 
of the disciplines that must be considered in the 
risk management activity. Organizationally the 
project risk management activity must consider 
the prime contractor, partners, other agencies, 
suppliers, academia, and other stakeholders on 
the project outside of the immediate government 
project team. 

All stakeholders have unique 
characteristics, strengths and weaknesses, 
resources and requirements/constraints, which 
can compliment and/or hamper risk 
management activity. The government project 
team is provided requirements, resources and 
given limits and deadlines which must be met. 
Into this environment come prime contractors 
and partners who must interact with the 
government team and understand and 
accommodate government requirements 
regarding such things as safety and risk 
management, and reconcile these requirements 
with their own internal processes in order to 
effectively deal and communicate with the 
government team and their partners. Involving 
other agencies further complicates the 
environment because integrating processes can 
be hampered by language barriers, differences 
in systems of measurement, cultural and 
political complexities, time zones and physical 
distances to name but a few. Risk management 
and the integration of risk management 
processes become even more important in this 
complex environment. The integration of risk 
management creates a network of 
communication common to all team members 
that can be used to identify, track and manage 
project risks regardless of source or location. 



disciplined level of management required in 
NASA projects today to meet mission success. 
This deliberate activity improves the chances of 
project mission success by surfacing risks that 
would perhaps get over looked, missed or 
improperly handled. 

Applying integrated risk management 
across the project provides the project team with 
the best chance at identifying risks that are 
important for mission success. By using the 
people, process, and project requirements/ 
constraints integrated risk approach projects 
allow the entire team to get involved in 
identifying risk, applying discipline to the 
process, and understanding the acceptable 
project risk. Figure- 1 illustrates integrated risk 
management across the project life cycle. This 
figure represents how the people, processes, and 
project requirements/constraints are an integral 
part of the Risk integration process. This figure 
represents the people, both organizationally and 
functionally that must be considered and 
integrated within the processes (System's 
Engineering processes, project management 
processes, and Continues Risk Management 
processes) and it identifies project requirements/ 


At NASA projects are required to follow 
NASA Policy Requirements (NPR). NPR 
7120.5 and NPR 8000.4 provide the 
requirements for project management and risk 
management respectively. The NASA systems 
engineering guidebook 6105 although not a 
requirement, is an important best practices 
reference that discusses the importance of good 
systems engineering and how risk management 
is an important part of Systems Engineering. 
Projects are required to follow 7120.5 because it 
provides a minimum set of requirements a 
project must perform to be successful and to 
manage risk. NPR 8000.4 provides 
requirements for a disciplined and rigorous 
Continuous Risk Management Process and 
explains that this process should be an integral 
part of project management. 

The remainder of this paper will discuss 
each risk integration element (people, process 
and project requirements/constraints) and how 
they are integrated and applied to project risk 
management in the integrated risk management 
concept. 
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Figure 1. 







Figure 2 shows that it must be recognized that 
everyone involved in the program or project 
must be a part of the risk management activity 
and integrated as one whole system. Suppliers, 
academia, and all other members of the 
program 'project team must be a pan of and 
support the risk management effort. All 
stakeholders must understand the process, their 
role in the process, and most importantly of 
all... the ultimate goal of the project, mission 
success. 


schedule slip?”, etc. The second key member is 
the “Subject Matter Expert”. This member 
provides the detailed knowledge and experience 
in the technology, operations, or process to be 
assessed. This member is the “optimist” asking 
the question “How will this be accomplished 
successfully? “How does it work?”, “How 
much time and money will it take?”. The third 
member is the “Decision-Maker”. This team 
member takes on the role of the “pragmatist ” 
asking the question “Is it acceptable?”, “What is 


All stakeholders have to be integrated into the RM process to make it work 
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The team approach is a significant element to a 
successful integrated risk management 
approach. A successful team should always be 
made of three key team members representing 
these three functions. The first is the 
Practitioner/Analyst. This member provides 
detailed experience in the use and application of 
the tools & techniques used to identify and 
analyze the potential risks. The 

Practitioner/Analyst is the “skeptic ” asking 
questions such as “How can it fail?”, “What is 
the weak link in the integration and test 
process?”, “Do these trends indicated a critical 


good enough given the constraints”, “Will this 
option provide the technical performance that is 
needed within the cost and scheduled constraints 
imposed? These functional areas are very often 
represented as follows: the Practitioner/ Analyst 
represented by Safety, Reliability & Mission 
Assurance; the Subject Matter Expert 
represented by Systems Engineering/Designers 
& Developers; and, the Decision-Maker 
represented by Program/Project Management. It 
is important to understand that these functional 
roles are dynamic and shift from organizational 
group to organizational group based on the risk 


being managed. For example when considering 
cost or schedule necessary to support the quality 
control of a critical fabrication process, the role 
Practitioner/Analyst may be represented by a 
budget analyst or scheduler in Program/Project 
Management. In this case the role of “Subject 
Matter Expert” is provided by the Quality 
Control Engineer. With the role of “Decision- 
Maker” taken up by the Systems Engineer or 
some other technical expert in the field. 

The NASA Goddard Space Flight Center 
(GSFC) Microwave Anisotropy Probe (MAP) 
Project provides a vivid example of how 
integrated risk management may be 
implemented for a spacecraft design and 
development project. As described by the MAP 
Mission Systems Engineer, (“The Systems 
Engineering Approach to Risk Management & 
Reliability on the MAP Project”, Michael Bay, 
Jackson & Tull, Aerospace Division supporting 
the NASA GSFC Systems Management Office, 
NASA risk Management Colloquium IH, 
September 18, 2002) the MAP Project included 
the entire project team in understanding how to 
implement an integrated risk management 
process by asking the following 
requirements/constraints related questions: 
“What makes a mission successful?” and “What 
makes a mission unsuccessful?”. Throughout 
the design and development process the MAP 
Project effectively applied project management, 
systems engineering, and mission assurance 
techniques in order to achieve a balance 
between requirements and constraints and 
between immediate, short-term risk mitigation 
vs. long-term mission success objectives. 

A key strategy used by the MAP Project 
was to integrate risks in terms of the collective 
impacts on safety, on-orbit technical 
performance, and project execution. This 
allowed the team to clearly address trades and 
risk mitigations with a an increased insight into 
the ultimate consequence avoiding the common 
pitfall of misunderstanding the what is truly a 
requirement and what is truly a constraint. A 
detailed set of criteria where established 
defining safety risks, acceptable mission risks, 
and acceptable development risks. These 
criteria were applied collectively in every case 


and for every risk in the risk management 
process to ensure that a comprehensive risk 
profile/risk exposure was defined. 

Integrated Risk Management Using Systems 
Engineering (SE), Safety and Mission 
Assurance (SMA) 

The SMA function is a vital part of the risk 
management team. The SMA assures that 
quality, safety, reliability, and risks are at 
acceptable levels before the next major phase of 
the project is attempted. Safety engineering and 
reliability engineering use functional policies 
and processes to identify and categorize risk. 
This also applies to other disciplines in 
management that track cost and schedule risk on 
the project. 

There is a definite overlap between 
safety, reliability, quality/mission assurance and 
risk management. Safety is focused on events 
and conditions that can cause injury or damage, 
reliability is focused on system performance 
failures or malfunctions, quality/mission 
assurance ensuring that the processes used are 
effectively communicated, documented, and 
controlled. When integrated each element plays 
a vital role in supporting the risk management 
process. 

There is a natural synergy among the 
main elements of a reliability program, a system 
safety program, and quality assurance program. 
A variety of techniques and methodologies fit 
together to achieve an effective integrated risk 
management process. These are predominately 
used in system safety and reliability to identify 
and analyze potential risks to a project or 
program. 

Quality/Mission Assurance provide a 
comprehensive approach for integrating these 
and other systems engineering elements by 
reviewing all necessary inputs, including policy 
documents, plans, specifications and contracts, 
to gain a full understanding of overall mission 
or system requirements. Quality/Mission 
Assurance ensures that documentation and 
continuous communication for the full life cycle 
are maintained among all of management, 
engineering, assurance, safety, and reliability 
disciplines. Often Quality/Mission Assurance 


provide the management support and services as 
the focal point for developing a tailored System 
Safety, Reliability, and Quality Assurance 
Program Plan in accordance with established 
policies, requirements, and guidelines. 

As the project proceeds through the life 
cycle, design reviews and testing are supported, 
analyses are updated to reflect changes and 
verification tracking through log/matrices are 
checked to ensure compliance including the 
following activities: 

■ Evaluating changes that impact a 
reliability prediction working closely 
with the project management, systems 
engineering and reliability/safety to 
recommend design improvements that 
maintain or improve baseline technical 
performance. 

■ Participating in reviews, 

■ Monitoring performance metrics 
throughout the process and recommend 
improvements, 

■ Monitoring Validation & Verification 
activities, 

■ Performing audits and vendor 
surveillance to verify conformance 

. ■ Establishing contract requirements for 
the project during phase- A of lifecycle 


This comprehensive approach allows early 
identification of potential problems (i.e., risks), 
so that they can be corrected to increase the 
likelihood of mission success. For example, 
detailed information from the Failure Mode and 
Effects Analysis, Failure Modes and Effects 
Criticality Analysis, and reliability predictions 
are used by the system safety engineers to help 
identify and categorize hazards and to determine 
failure probabilities. Likewise, design changes 
incorporated to enhance safety must be 
evaluated to update reliability, availability and 
risk assessments by reliability engineering. 
Quality/Mission assurance support both safety 
and reliability by tracking the effectiveness of 
the design changes and other measures used to 
mitigate potential risk and by providing 
structured & disciplined methods for 
documenting and communicating the status of 


these activities. Although often considered to be 
a separate processes integrating safety, 
reliability, and quality assurance ensures a 
comprehensive approach to managing risk. 

The process Part of integrated risk 
management 

The process part of risk integration ties 
in the project life cycle process from phase- A 
through phase-E, continuous risk management 
process, Safety and Missions Assurance 
Process, and the systems engineering process, as 
described by NPRs 7120.4 and 8004, NPD 
8700.1, and NASA SE handbook 6105 
respectively. 

NASA has a policy that all NASA 
Programs and Projects consider risk when 
conducting day-to-day operations and that risk 
management be a part of all planning and 
decision-making. All Programs and Projects are 
required to have a Risk Management Plan and to 
create and maintain a Risk List in order to help 
capture their risks and track their risk mitigation 
efforts. NASA policy also identifies a 
continuous risk management (CRM) process. 
NASA adopted the CRM process in 1995 and a 
systems level course was developed for risk 
management that provides information on risk 
management implementation. This course was 
developed in a collaborative effort with the 
Software Engineering Institute at Carnegie 
Mellon University, and tailored to the NASA 
community. Since its inception, the CRM 
course has been presented more than 200 times 
to NASA Programs and Projects and to 
government organizations external to NASA as 
well. Figure 3 depicts the Continuous Risk 
Management process as a wheel, representing 
the continuous, iterative nature of risk 
management. 

The five steps of the process. Identify, 
Analyze, Plan, Track and Control surround the 
central theme of Communicate and document... 
the key to successful risk management. By 
maintaining good internal and external 

communication pathways and by integrating 
risk management seamlessly into the 

Program/Project infrastructure we can enhance 
performance and increase mission success. 




The relationship between the risk 
management process and other processes such 
as the Systems Engineering process, Safety and 
Mission Assurance process, and the 
Program/Project Management process is 
symbiotic. Each of these processes exists 
separately and can perform its functions on its 
own but when combined, when integrated with 
one another they become greater than the sum of 
their parts. Each process benefits from and 
feeds each of the other processes, 
complimenting each and providing each process 
with added insight and awareness that provides 
decision makers with a much clearer 
understanding of the health of their project. 


Figure 4 depicts the continuous risk 
management flow' process, demonstrating inputs 
and outputs at each of the five stages. 

Although risk management begins early in 
formulation it should be understood that the 
process continues and is a part of the project 
from the cradle to the grave. 



Figure 4. 

















Starting Risk management early in the 
lifecycle (Risk management in acquisition): 

Starting risk management early in the 
life cycle has tremendous benefits to the project. 
An early start lays the foundation for how you 
will manage risk for the entire program/project 
life cycle. The Risk based acquisition 
management (RBAM) process is a fundamental 
part of risk management and is in the NPR 
7120.5b. RBAM helps identify acquisition risk 
and provide decision makers with information 
that allows them to see Risk information relative 
to the source selection of a prime contractor. 
The other benefit of RBAM is that it allows the 
project to establish risk based surveillance 
requirements along with award fee and contract 
incentives based on assessed contract risk. 
Figure 5 shows the RBAM process. RBAM is 
integrated with the CRM process at the very 
early stages of the project. Prior to contract 
award the RBAM process helps identify 
contract risk so decision makers can analyze, 
plan, track, and mitigate those risk before they 
become problems. RBAM serves as a means to 
let managers know what information should go 
in the contract prior to contract award. 


RBAM serves as an integration process to get 
SE, SMA, Resource management, and Project 
management information in the contract prior to 
contract award. What goes into the contract sets 
the tone for how RM is to be performed 
throughout the project lifecycle. 

The project requirements/constraints part of 
integrated risk management 

The project requirements/constraints part 
of risk management obviously takes into 
consideration the requirements and constraints 
associated with cost, schedule, safety and 
technical performance. 

The risk management process is in itself 
the glue that binds the three pivotal disciplines. 
In general risk management considers risks that 
integrate the following three characteristics: 
technical, cost, and scheduled. All to often the 
focus is on just a single characteristic with little 
consideration given to integrating and balancing 
the risk with the other characteristics. As an 
example, the consequences and mitigations for a 
technical risk are often limited to addressing the 
technical issue at hand with the other 
characteristics of risk viewed as constraints. 
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Figure 5. 



That is to say: the engineering will for the most 
part address the details related to the 
identification, analysis, and mitigation of the 
technical aspects of the risks. All the while 
looking at the other characteristics of risks, not 
as integrated elements of the same risk, but as 
constraints either as a contributing factor in 
creating the original risk or as a limit to the level 
of mitigation possible. 

In the integrated approach to risk 
management all of the relevant characteristics 
must be evaluated in a balanced way when 
identifying, analyzing, and mitigating risk. 
Should the project manager spend a $1M to 
achieve the technical performance within the 
allocated schedule; or should the project 
manager reduce the technical requirements in 
favor of maintaining the budget and schedule? 

When considering the potential risk 
impact technical, cost, and schedule are 
generally identified. Similarly, risks are often 
identified in terms of technical, cost, and 
schedule. Risks are most affectively dealt with 
when technical, cost, and schedule are viewed 
as inherent characteristics of all risks integrated 
across the entire spectrum of impacts. This 
perspective allows for the identification, 
analysis, and ultimately mitigation of risks in a 
balanced and integrated manner. Ensuring that 
all aspects of the risks are evaluated and 
appropriately mitigated. 

Perspective plays a significant role in 
risk management. “One person’s risk is another 
person’s constraint”. Consider for a moment the 
traditional segregated process for risk 
identification, analysis, and mitigation. In this 
traditional approach, the engineer considers all 
the potential technological, design, and testing 
risks in achieving a particular technical 
performance. The project scheduler considers 
all the schedule slips, the slack, the variances 
between planned and actual schedule dates, and 
critical path risks in maintaining a particular 
schedule. The resource manager s imil arly 
considers risks in terms of personnel, cost, and 
other types of resources. In each case, the given 
risk perspective often considers the other 
elements as constraints to either achieving the 
objective or as a constraint to fully mitigating a 


given risk. So the engineer’s perspective may 
state as “any technical performance can be 
achieved given enough time and money”. 

The integration of risk across these 
disciplines and across the lifecycle has been 
accomplished as an example on the MAP 
Project at the Goddard Space Flight Center. 
Current examples of this integration and 
balancing are evidenced by the current 
implementation of Risk Management on the 
Global Precipitation Management (GPM), and 
Solar Dynamics Observatory (SDO) projects, 
and James Webb Space Telescope (JWST) 
program. The JWST program is an example of 
this integration across larger organizations. 
GPM and SDO are examples of integration 
across disciplines using a balanced approach to 
mitigate risks. The JWST program provides a 
good example of integration across multiple 
organization and multiple functional tiers. 

Summary: 

Integrated Risk management is a disciplined and 
deliberate risk management activity that 
involves a systemic approach and covers the 
entire project life cycle. It primarily involves the 
people, process, and project 
requirements/constraints of the project. The 
primary benefit of risk integration is it gets all 
of the stakeholders involved in the process and 
creates communication and dialogue among 
team members who would otherwise not 
communicate with one another. It forces leaders 
to report and identify acceptable risk, and allows 
the project manager to make more informed 
decisions. Integrated risk management is not a 
discipline in and of itself but a part of all 
management activity including project 
management, systems engineering management, 
and functional management (safety, reliability, 
etc.). All stakeholders must be involved in risk 
management to be successful. The process part 
deals with understanding policy requirements 
and applying them in a way that benefits the 
project. The process also involves the 
understanding of roles and responsibilities of all 
the stakeholders on the project team. 
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